hhkb
AI

에이전트시스템_02_에이전트 분업과 평가 루프

작성자 : Heehyeon Yoo|2026-03-25
# 에이전트시스템# 멀티에이전트# 평가루프# 자기평가# 오케스트레이션

1. 에이전트를 나누는 이유

에이전트 시스템에서 분업이 자꾸 등장하는 이유는 단순하다. 한 에이전트에게 계획, 구현, 검증을 한꺼번에 맡기면 각 단계의 경계가 흐려진다. 특히 긴 작업에서는 더 그렇다. 방금 세운 계획을 스스로 다시 수정하고, 그 결과를 또 스스로 평가하게 되면 잘못된 방향으로 간 뒤에도 그걸 알아채지 못하는 경우가 많다.

Anthropic이 planner, generator, evaluator 구조를 쓴 이유도 여기 있다. 이 구조는 겉으로 보면 멀티에이전트 패턴처럼 보이지만, 실제로는 실패 위치를 분리하는 장치에 더 가깝다. 계획이 틀린 건지, 구현이 어설픈 건지, 평가 기준이 약한 건지를 나눠서 볼 수 있어야 긴 작업을 유지하기 쉽다.

이 점에서 분업은 역할놀이가 아니다. "에이전트를 여러 개 쓰면 더 똑똑해진다"는 얘기도 아니다. 어떤 판단을 같은 세션 안에 섞어 두면 왜곡이 생기는지를 줄이기 위한 구조에 가깝다.

2. 자기평가가 잘 안 되는 이유

Anthropic 글에서 가장 설득력 있는 부분은 자기평가 문제다. 에이전트는 자기가 만든 결과물에 대체로 후하다. 겉보기에 그럴듯하면 실제 결함을 놓치기 쉽고, 기준이 모호할수록 더 쉽게 넘어간다. 디자인처럼 정답이 없는 작업에서는 특히 심하다. "좋다"와 "그럴듯하다"를 구분하지 못한 채 높은 점수를 주는 경우가 많다.

그래서 evaluator를 분리하는 건 단순한 역할 추가가 아니다. 평가를 밖으로 꺼내는 일이다. Anthropic은 디자인 작업에서 design quality, originality, craft, functionality처럼 기준을 쪼갰다. 이게 중요한 이유는 미감을 숫자로 환원했다는 데 있지 않다. 막연한 감상을 채점 가능한 항목으로 바꿨다는 데 있다.

이 구조는 코딩에서도 그대로 쓰인다. 테스트를 통과했다고 해서 제품 품질이 자동으로 확보되는 건 아니다. 기능은 돌아가는데 흐름이 어색하거나, 계약한 범위를 벗어나거나, 구현 품질이 낮은 경우는 계속 나온다. 그래서 evaluator는 버그를 찾는 역할만 하는 것이 아니라, "이번 결과물이 애초에 만들기로 한 것에 맞는가"까지 같이 본다.

3. planner, generator, evaluator

planner는 짧은 요구사항을 바로 구현 단계로 넘기지 않는다. 먼저 작업 범위와 구조를 풀어 쓴다. 여기서 중요한 건 세부 구현을 다 적는 게 아니다. 오히려 그 반대다. Anthropic도 planner가 너무 이른 단계에서 세세한 구현을 못 박아 버리면, 그 오류가 아래로 전파된다고 봤다. 그래서 planner는 제품 맥락과 큰 방향을 정리하는 쪽에 더 가깝다.

generator는 그 계획을 한 번에 다 처리하지 않는다. 보통 feature 단위나 sprint 단위로 나눠서 가져간다. 이 방식이 중요한 이유는 큰 작업을 작은 실행 단위로 바꾸기 때문이다. 작업 단위가 너무 크면 실패 원인도 커지고, 성공 여부도 흐려진다.

evaluator는 마지막에 결과물을 훑는 QA 담당처럼만 보면 부족하다. 실제로는 작업 경계 자체를 정하는 역할까지 맡는다. Anthropic이 말한 sprint contract가 그 예다. 이번 턴에서 무엇을 만들 것인지, 완료 조건은 무엇인지, 어떤 방식으로 검증할 것인지를 generator와 evaluator가 먼저 맞춘다. 즉 평가는 끝에 붙는 단계가 아니라, 구현 전에 작업 단위를 닫아 두는 장치이기도 하다.

4. 평가 루프는 반복의 구조다

평가 루프의 핵심은 한 번 점수 주고 끝내는 데 있지 않다. generator가 결과를 만들고 evaluator가 비판을 돌려주고, 그 피드백이 다시 다음 시도의 입력이 되는 구조 자체가 중요하다. Anthropic이 디자인 작업에서 5회에서 15회 정도 반복을 돌린 것도 이 때문이다. 결과가 한 번에 좋아지는 게 아니라, 평가 기준을 따라 방향을 수정하는 쪽이 더 강하게 작동했다.

여기서 봐야 할 건 반복 횟수보다 피드백의 질이다. evaluator가 막연한 칭찬만 하면 루프는 사실상 죽는다. 반대로 기준이 너무 세거나, 매번 다른 잣대를 들이대면 generator는 어디를 고쳐야 하는지 못 잡는다. 그래서 좋은 평가 루프는 엄격해야 하지만 동시에 일관되어야 한다.

이 말은 결국 평가 기준을 시스템 바깥에 분명하게 적어 둬야 한다는 뜻이다. 점수표, 실패 조건, 통과 임계값, contract 문서가 다 여기 속한다. 좋은 루프는 에이전트가 알아서 감각적으로 움직이는 구조가 아니라, 수정 방향이 계속 남는 구조다.

5. 분업은 비용도 만든다

에이전트를 나누면 당연히 비용이 늘어난다. planner가 추가되면 방향은 또렷해지지만 초반 단계가 무거워진다. evaluator가 붙으면 품질은 올라가지만 반복 횟수, 실행 시간, 토큰 비용이 함께 늘어난다. contract를 협상하는 단계까지 넣으면 구현 속도는 더 느려질 수 있다.

그래서 핵심은 에이전트를 많이 두는 데 있지 않다. 어떤 판단을 분리해야 실제 실패가 줄어드는지 고르는 데 있다. 자기평가가 문제라면 evaluator 분리가 의미가 있다. 요구사항이 계속 흔들린다면 planner나 contract 단계가 필요할 수 있다. 반대로 단순한 작업이라면 분업이 오히려 과하다.

결국 에이전트 분업은 구조를 복잡하게 만드는 기술이 아니라, 실패를 더 빨리 드러내기 위한 기술에 가깝다. 평가 루프도 품질을 예쁘게 꾸미는 장치가 아니라, 에이전트가 자기 착각에 빠진 채 계속 달리는 걸 멈추게 하는 장치로 보는 편이 맞다.

참고 자료